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(57) ABSTRACT 

A system that permits commercial transactions over a net- 
work of computers is described. In one example, the net- 
work of computers supports communications between busi- 
ness relation data structures. The business relation data 
structures reflect credit relationships between two or more 
businesses. To perform a commercial transaction, a con- 
sumer accesses a vendor's Web site. The consumer selects 
an item to purchase from that Web site. The vendor com- 
puter then generates a proposal. The proposal includes an 
item identifier and a price. That proposal is then propagated 
to all of the business relation data structures with which the 
vendor's business relation data structure can communicate. 
At each one of the recipient business relation data structures, 
the proposal is modified and forwarded on to other business 
relation data structures. The modifications are based upon 
the credit relations between businesses. This modification 
and forwarding continues until the consumer's computer is 
reached with a set of proposals. The consumer then accepts 
a proposal that best suits her needs. This acceptance is then 
propagated back to the vendor computer. The vendor can 
then deliver the item to the consumer. 
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INTERNET COMMERCE METHOD AND 
APPARATUS 

RELATED APPLICATIONS 

[0001] This application relates to, claims the benefit of the 
filing date of, and incorporates by reference, the United 
States provisional patent application serial No. 60/072,473, 
entitled "Internet Commerce Method and Apparatus," inven- 
tor Jacques Quelcne, filed Jan. 26, 1998. 

COPYRIGHT NOTICE 

[0002] A portion of the disclosure of this patent document 
contains materials that arc subject to copyright protection. 
The copyright owner has no objection to the facsimile 
reproduction by any one of the patent disclosure, as it 
appears in the Patent and Trademark OfEce patents, files or 
records, but otherwise reserves all copyright rights whatso- 
ever. 

BACKGROUND OF THE INVENTION 
[0003] 1. Field of the Invention 

[0004] This invention relates to the field of networked 
computer systems and more particularly the invention 
relates to using networked computer systems to conduct 
electronic commerce. 

[0005] 2. Description of the Related Art 

[0006] Electronic commerce is rapidly growing. Increas- 
ing numbers of purchases are being conducted electronically 
over public networks like the Internet as well as private 
networks such as corporate intranets. To date, electronic 
commerce has primarily been employed in the delivery of 
tangible goods such as computer equipment, bouquets of 
flowers, airline tickets, etc. Electronic commerce can also be 
used in the delivery of digital products such as newspaper 
articles, stock quotes, database query results, movies, etc. 
Electronic commerce primarily reduces business channel 
costs. These are the costs associated with processing orders, 
credit checking, handling payments, etc. Electronic com- 
merce is important for the delivery of digital products in 
order to keep costs in line with the value of the digital 
products. 

[0007] Accordingly, vendors should adopt a method for 
electronic commerce suitable to the types of transactions 
that they will be doing with their purchasers. There are three 
ways vendors presently enable purchasers to participate in 
electronic commerce: using accounts, accepting credit cards, 
and accepting electronic cash. Each of these solutions is a 
variation of traditional commerce methods. 

[0008] Account based solutions are modeled on the way 
companies traditionally did business with one another pur- 
chase orders and invoices. This system requires that vendors 
know purchasers because the vendor is extending the credit. 
Further, as the number of purchasers increases, the paper- 
work involved in handling the purchase orders and billing 
customers becomes immense. Although electronic com- 
merce eliminates some of the paperwork, and partially 
automates the systems, account based solutions are not 
efficient for either the purchaser or the vendor. Purchasers 
are required to remember account information for a multi- 
tude of vendors and vendors are required to take on a 



secondary business of providing credit. Given these limita- 
tions, it is unsurprising that account based systems are 
generally not in widespread use in electronic commerce. 

[0009] Credit card based transaction systems eliminate the 
credit issue for vendors, but incur other costs. Credit card 
providers charge 1-3% on each transaction. This charge 
covers the costs for security, insurance, and the centralized 
system. This charge makes using credit cards for small 
purchases unattractive. When electronic commerce is used 
for the purchase of expensive tangible goods, like computer 
equipment or plane tickets, credit cards function as well as 
they do outside the electronic commerce realm. However, it 
is not feasible to use credit cards for the types of low cost, 
information-oriented transactions that are a component of 
electronic commerce. 

[0010] Credit card transactions also do not support mul- 
tiple currencies with ease. A vendor might present a pur- 
chaser with a display of different currencies, as an indication 
of the price, but the actual exchange rate that will be in effect 
when the credit card company settles the accounts may be 
different. Thus, credit cards do not support reliable pricing 
in a multi -currency environment. 

[0011] Credit cards also do not work well in business 
settings. The credit card approval process looks only to the 
credit limit on the card, e.g. the credit of the business or the 
credit line on that corporate card, and not to the budget or 
authorization process of the company. Further, the company 
has no control over the purchasing process until after a firm 
commitment has been made, e.g. when the statement is 
issued. Therefore, it is not possible to enforce business 
specific rules on credit card purchases. Credit cards also do 
not work well for detailed expense tracking. It is difficult at 
the time of purchase to associate internal tracking or account 
information with a purchase. 

[0012] Electronic cash solutions have been created to 
address some of the shortcomings of credit cards for elec- 
tronic commerce. A buyer gets "coins" from her/his bank, 
and gives them to a merchant when she/he has to pay. The 
"coins" are stored as electronic cash either on a smart card 
or in a software application on a computer. Duplicating a 
sequence of bits is a lot easier than counterfeiting physical 
coins or notes, so any electronic cash solution must have 
systems for verifying the electronic cash and preventing 
double spending. This requires that the electronic cash be 
verified by the bank at transaction time. These costs limit the 
use of the system to transactions that involve at least $0.50. 
Thus, it is not feasible to use electronic cash for the types of 
low cost-information oriented transactions that are a com- 
ponent of electronic commerce. 

[0013] In addition, the various technologies do not cur- 
rently interoperate. Unlike the credit card industry that is 
dominated by a small number of mature providers with a 
high degree of market penetration, electronic cash solutions 
have a low degree of market penetration. Thus, both the 
merchant and the buyer must have accounts with the same 
electronic cash provider. 

[0014] Present electronic commerce solutions are not well 
suited to commerce between vendors and purchasers that do 
not know one another. Present electronic commerce solu- 
tions are too costly on a per transaction basis for low priced 
information purchases that could make up the bulk of 
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electronic commerce. Present electronic commerce solu- 
tions do not operate well between different payment meth- 
ods. Present electronic commerce solutions do not easily 
permit multi-currency transactions. Accordingly, what is 
needed is an electronic commerce technique that permits 
vendors and purchasers to complete extremely large vol- 
umes of transactions with very little transactional overhead 
in multiple currencies with differing types of payment 
methods. 

SUMMARY OF THE INVENTION 

[0015] Some embodiments allow for electronic commerce 
over a computer network. The network has a purchaser 
computer and a vendor computer. The network supports 
business relation structures that represent agreements to 
extend credit between businesses. The network uses the 
business relation structures for decision making processes. 
The network transmits business messages that relate to 
agreements between businesses, including messages relating 
to extending credit for purchases. 

[0016] In some embodiments, the vendor computer creates 
a proposal. That proposal identifies an item to be purchased 
as well as the vendor price and other transaction parameters. 

[0017] In one embodiment, the proposal is sent to an 
intermediary that shares a business relation with the vendor. 
This intermediary sends the proposal to other intermediaries 
via the network until one or more proposals reaches the 
purchaser. At each stage, the proposal is modified by the 
intermediary. The modifications can include changing the 
price to reflect the cost of extending credit and the value 
added by the intermediary. The purchaser computer may 
receive multiple proposals depending on the number of 
paths between the vendor and the purchaser. 

[0018] A selection signal is received on the purchaser 
computer that indicates the purchaser wishes to accept one 
of the proposals. The selected proposal is then transmitted to 
the vendor computer, along the same path as the initial path. 
At that point, the transaction is complete and the vendor 
delivers the good, or service, identified by the proposal 

[0019] In some embodiments, the vendor price is specified 
in the vendor's currency and the proposal specifies that the 
purchaser computer requires the price specified in a different 
currency. The price associated with some of the proposals is 
then specified in the purchaser's currency and charges are 
added to the vendor price of those proposals for performing 
the currency conversion. 

[0020] In some embodiments, the computers attach cryp- 
tographic signatures to the proposals and the selected pro- 
posal. For example, a vendor computer might only accept 
proposals that are cryptographic ly signed by the purchaser 
computer. 

[0021] In some embodiments, a receipt is issued by the 
vendor computer when the vendor receives the selected 
proposal. 

[0022] In some embodiments, credit histories and trans- 
action performance histories limit the search of the business 
relation structures. For example, business relation structures 
that indicate a business has poor credit history will not be 
included in the paths found by the search of the business 
relation structures. 



[0023] In some embodiments, the vendor can quickly 
establish a commerce site from an existing web site by 
associating a flag containing a price with content and goods 
that come with a price. Then, the vendor operates a cash 
register program so that the data flowing from the web server 
to the client is intercepted by the cash register. The cash 
register delays delivery of the data to the client while a 
proposal is generated and routed to the client. Once the 
proposal has been accepted, the cash register will complete 
the delivery of the requested data to the client. 

BRIEF DESCRIPTION OF THE FIGURES 

[0024] FIG. 1 illustrates one embodiment of the invention 
with computer systems coupled in a network supporting 
transactions between the computer systems on the network. 

[0025] FIG. 2A illustrates one embodiment of a method of 
completing a transaction. 

[0026] FIG. 2B illustrates one embodiment of a method of 
searching the business relation structures to generate a set of 
proposals. 

[0027] FIG. 2C illustrates one embodiment of a method of 
transmitting the accepted proposal to the vendor computer. 

[0028] FIG. 3 illustrates computer systems that supports 
extranets. 

[0029] FIG. 4 illustrates computer systems that supports 
greater corporate control of transactions. 

[0030] Although many details have been included in the 
description and the figures, the invention is defined by the 
scope of the claims. Only limitations found in those claims 
apply to the invention. 

DETAILED DESCRIPTION 
[0031] A. System Overview 

[0032] FIG. 1 depicts networked computer systems 
including an embodiment of the invention. FIG. 1 includes 
a physical and a higher level view of the system. The 
following first lists the elements of FIG. 1, then describes 
the elements, and then describes how they work together. 

[0033] This paragraph lists the elements in FIG. 1. FIG. 
1 shows a physical layer 100 comprising: an IP Network 
101, a computer 102, a computer 103, a computer 104, a 
computer 105, a computer 106, a computer 107, a computer 
108, a computer 109, a computer 110, a computer 111, and 
a computer 112. FIG. 1 also shows a communications layer 
170 comprising: the cash register programs 114, a cash 
register(CR) 115, a CR 116, the trader programs 120, an 
internet trader (IT) 121, an IT 122, an IT 123, an IT 124, an 
IT 125, the manager programs 130, an account manager 
(AM) 131, the purchaser programs 140, an internet pur- 
chaser (IP) 141, an IP 142, an IP 143, the business links 160, 
a business link (BL) 150, a BL 151, a BL 152, a BL 153, a 
BL 154, a BL 155, a BL 156, a BL 157, a BL 159, a BL 161, 
a BL 162, and a BL 163. 

[0034] This paragraph describes the interconnections 
between the elements of FIG. 1. The IP Network 101 is 
coupled to the computer 102, the computer 103, the com- 
puter 104, the computer 105, the computer 106, the com- 
puter 107, the computer 108, the computer 109, the com- 
puter 110, the computer 111, and the computer 112. The CR 
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115 is coupled to the IT 121 by the BL 150. The CR 116 is 
coupled to the IT 121 by the BL 151. The IT 121 is coupled 
to the IT 122 by the BL 152. The IT 121 is coupled to the 
IT 123 by the BL 153. The IT 122 is coupled to the IT 124 
by the BL 154. The IT 123 is coupled to the IT 124 by the 
BL 155. The IT 121 is coupled to the IT 125 by the BL 156. 
The IT 124 is coupled to the IT 125 by the BL 157. The IT 
124 is coupled to the AM 131 by the BL 159. The AM 131 
is coupled to the IP 141 by the BL 161. The AM 131 is 
coupled to the IP 142 by the BL 162. The AM 131 is coupled 
to the IP 143 by the BL 163. 

[0035] The following paragraphs describe the elements of 
FIG. 1. The physical layer 100 corresponds to the underly- 
ing physical computers and network over which electronic 
commerce occurs. The IP Network 101 is the Internet, or any 
network, such as an intranet, an extranet, or a private 
switched network. The computer 102, the computer 103, the 
computer 104, the computer 105, the computer 106, the 
computer 107, the computer 108, the computer 109, the 
computer 110, the computer 111, and the computer 112 may 
be personal computers, handheld computers, workstation 
computers, server computers, clusters of computers, or some 
other computer. Computers used by the purchaser programs 
140 are more likely to be personal computers, handheld 
computers, television set -top boxes, or thin client computers 
like the Network Computers proposed by Sun, Oracle and 
IBM, but this is not required. 

[0036] The cash register programs 114, the trader pro- 
grams 120, the manager programs 130, and the purchaser 
programs 140 maintain business relation structures contain- 
ing computer readable information about business relations. 
The business links 160 represent the communications chan- 
nels between business relation structures. The communica- 
tions layer 170 shows the network formed by the business 
relation structures. 

[0037] The cash register programs 114, the trader pro- 
grams 120, the manager programs 130, and the purchaser 
programs 140 may be computer programs, computer pro- 
cesses, computer tasks, or some other computer executable 
code. A computer program is a sequence of instructions for 
a computing device. 

[0038] The cash register programs 114 include the CR 115 
and the CR 116. The cash register programs 110 are operated 
by businesses or individuals that have products, either 
tangible or digital, for sale. Products can be either a product 
or a service. Collectively the operators of the cash register 
programs 110 are called vendors. The cash register programs 
110 allow vendors to request and collect money from 
purchasers for products the vendor is selling by using a 
scries of intermediaries to extend credit to the purchaser. 

[0039] The trader programs 120 include the IT 121, the IT 
122, the IT 123, the IT 124, and the IT 125. The trader 
programs 120 arc operated by businesses or individuals that 
act as intermediaries in transactions between vendors and 
purchasers. Collectively the operators of the trader programs 
120 are called intermediaries. The intermediaries act as 
creditors and debtors with one another. Intermediaries 
relieve vendors of the burden of acting as creditors to their 
purchasers. This has the effect of increasing the amount of 
credit available to purchasers because it permits purchasers 
to buy from vendors who do not know them. The interme- 
diaries may have the trader programs 120 assess charges to 



cover the costs of extending credit for a transaction. The 
trader programs 120 help the intermediaries perform these 
functions. 

[0040] The manager programs 130 include the AM 131. 
The manager programs 130 are operated by businesses or 
individuals that provide credit services to purchasers, such 
as invoicing and billing, or other value added services, such 
as training. Collectively the operators of the manager pro- 
grams 130 are called account managers. They can be regular 
account managers, corporate account managers, or gateway 
account managers. Gateway account managers can enable 
different payment techniques. For example, a gateway 
account manager could accept payments using the secure 
electronic transaction (SET) protocol for credit cards. The 
purchaser account mangers may have the manager programs 
130 assess charges to cover the costs of extending credit for 
a transaction. 

[0041] The purchaser programs 140 include the IP 141, the 
IP 142, and the IP 143. The purchaser programs 140 are 
typically operated by individuals seeking to purchase prod- 
ucts. The purchaser programs 140 may also operate inde- 
pendently of an individual based on user or corporate 
preferences and requests. Collectively the operators of the 
purchaser programs 140 are called purchasers. The pur- 
chaser programs allow purchasers to purchase goods. 

[0042] In the example of FIG. 1, the CR 115 is running on 
the computer 103. The CR 116 is running on the computer 
105. The IT 121 is running on the computer 104. The IT 122 
is running on the computer 102. The IT 123 is running on the 
computer 123. The IT 124 is running on the computer 112. 
The IT 125 is running on the computer 107. The AM 131 is 
running on the computer 111. The IP 141 is running on the 
computer 110. The IP 142 is running on the computer 109. 
The IP 143 is running on the computer 108. The invention 
does not rely on the locations of the participants to a 
transaction in the physical layer 100. It is possible for the 
same computer in the physical layer 100 to operate multiple 
programs and play multiple roles. 

[0043] The individuals and businesses that are vendors, 
purchasers, intermediaries, and account managers form 
business relations to conduct business. A business relation 
structure represents an agreement between two or more 
entities to extend credit to one another. Typically, a pur- 
chaser will select one or more account managers to handle 
his/her purchasing needs. The business relationship between 
purchaser and account manager is that of debtor and creditor 
respectively. When a corporation acts as the account man- 
ager, the account manager program serves to control pro- 
posed spending decisions by purchasers, e.g. purchasing 
agents of the corporation. 

[0044] Vendors similarly will select one or more interme- 
diaries to extend credit to purchasers on their behalf. The 
business relationship between vendors and intermediaries is 
that of creditor and debtor respectively. Intermediaries will 
form agreements and partnerships with other intermediaries. 
The business relationships between intermediaries can take 
many forms. For example, an intermediary might agree to be 
a debtor to another intermediary, but refuse to extend credit 
to that intermediary because of a bad past payment history. 
Account managers form business relations with one or more 
intermediaries. The business relationship between account 
managers and intermediaries is that of debtor and creditor 
respectively. 
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[0045] If it is possible to find a sequence of business links 
between a vendor and a purchaser, then that vendor and that 
purchaser can do business with one another. For example, 
the CR 115 and the IP 141 can do business with one another 
because <BL 150, BL 152, BL 154, BL 159, BL 161> is a 
sequence of business links that couple the CR 115 and the IP 
141. In the example and FIG. 1, it is possible for all the 
vendors and all the purchasers to do business with one 
another because at least one sequence of business links can 
be found between each vendor and each purchaser. 

[0046] The steps for completing a transaction will now be 
described. When a purchaser using the IP 141 is reviewing 
the goods the CR 115 has for sale, the IP 141 sends a 
selection signal to the CR 115 indicating an item the IP 141 
is interested in purchasing. In some embodiments, the CR 
115 uses the World Wide Web (WWW) to present the items 
for sale. The CR 115 is able to use other protocols to present 
the items for sale such as electronic mail messages, file 
transfer protocol file transmissions and the like. Using 
commercially available browser software such as Netscape 
Navigator™, the IP 141 sends the selection signal to the CR 
115 by transmitting the address of a link embedded in the 
WWW page to the CR 115. The address corresponds to the 
item the IP 141 wishes to purchase. The CR 115 will then 
generate a proposal identifying a good for sale and the price 
of the good. 

[0047] Rather than deciding whether the IP 141 is a good 
credit risk, the CR 115 will take advantage of the network 
created by the business links 160 and the corresponding 
business relations to enable the purchase. The business 
relation structures will be used to convey the proposal to the 
IP 141. Each program in the network of business links may 
add a different markup for the credit services provided. The 
markup is based on the business relations needed to extend 
credit as well as the value added services, if any, provided 
by the business relations. For this reason, multiple proposals 
for the purchase of the same good may be transmitted to the 
IP 141. Each proposal will correspond to a different 
sequence of business links between the CR 115 and the IP 
141. 

[0048] In this example, the IP 141 has signaled to the CR 
115 that it is interested in proposals for the purchase of a 
specific good. The CR 115, after generating the proposal, 
then transmits the proposal to all of its business relations as 
identified in business relation structures. In this case the CR 
115 transmits the proposal to the IT 121. The IT 121 then 
examines the proposal and decides whether to facilitate the 
proposal. Assuming the IT 121 decides to facilitate the 
proposal, the IT 121 will add a markup for extending credit 
and transmit the proposal over the network to some or all of 
its business relations based on the information stored in the 
routing tables of IT 121. This process of reviewing the 
proposal and forwarding it to business relations continues 
until one or more modified proposals reach the IP 141. 

[0049] In this example, the IT 121 sends the proposal to 
the IT 122 and the IT 123. The IT 122 sends the proposal to 
the IT 124. The IT 123 sends the proposal to the IT 124 and 
the IT 125. The IT 125 sends the proposal to the IT 124. The 
IT 124 sends three different proposals for the same identified 
good to the AM 131. The three proposals will be different 
because each reached the AM 131 by a different sequence of 
business links and thus the price, and perhaps other terms, 
will differ among the proposals. 



[0050] After adding its markup, the AM 131 sends the 
proposals to the IP 141. The IP 141 then receives a selection 
signal indicating which proposal out of the set of proposals 
that have been received is accepted. The process of receiving 
the selection signal is described below. 

[0051] Once that selection is made, the selected pro- 
posal — or order — is transmitted back to the manager pro- 
grams 130, the trader programs 130, and then the CR 115 in 
reverse order from the sequence of business links that 
correspond to the order. 

[0052] When the CR 115 receives the order, the contract 
has been made. It is time for the CR 115 to deliver the 
purchased good. The CR 115 also sends a receipt to the IP 
141. The receipt indicates the goods that were purchased by 
the IP 141. In one implementation, the receipt can also be 
used by IP 141 to re -request the purchased data for a 
predetermined period. 

[0053] At appropriate intervals, defined by the business 
relations, the entities in the business relations pay back the 
credit extended. Different business relations may define 
different payment terms. For example, the purchaser pro- 
grams 140 are typically operated by individuals who might 
be billed on a weekly or monthly basis. The trader programs 
120 are typically operated by banks and other large business 
and as such, they might adopt policies that require more 
frequent payments. Regardless of the amount of credit 
extended or the number of transactions, participating entities 
can always provide their business relations with detailed 
invoices describing the transactions for which debt is owed. 

[0054] This process of conveying the proposals across the 
business links 160 from the cash register programs 114 to the 
purchaser programs 140 occurs quickly. To speed the pro- 
cess, the trader programs 120 may employ caching algo- 
rithms that speed the identification of business relations on 
the path to the IP 141. The trader programs 120 may also 
employ heuristics to limit the extension of credit to bad 
credit risks or favor the use of business relations that result 
in a higher percentage of accepted proposals. For example, 
the IT 123 might recognize that only 10% of the proposals 
the IT 123 sent to the IT 125 have been accepted, but 90% 
of the proposals it sent to the IT 124 have been accepted. 
Accordingly, the IT 123 might send fewer proposals to the 
IT 125. 

[0055] As transactions occur and business relation struc- 
tures are modified, the business links 160 are added and 
removed. The communications layer 170 changes as the 
business links 160 are added and removed. Thus, the ability 
of a vendor and a purchaser to transact business depends on 
the status of the communications layer 170. For example, if 
the IT 124 is a small intermediary with low credit limits with 
its business relations, then there may be occasions on which 
the CR 115 and the IP 141 can not do business until the IT 
124 has paid down its debt. Similarly, the IT 122 might owe 
the IT 121 the maximum amount of money allowed by the 
business relation between the parties, accordingly the IT 121 
will not transmit further proposals to the IT 122 until the IT 
122 pays down its debt. 

[0056] If there are no paths between the CR 115 and the IP 
141 in the communications layer 170, the CR 115 will 
transmit an error message to the IP 141 using the physical 
layer 100. The error message can include information 
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describing the problem and, if appropriate, the identity of the 
program that refused to extend credit. 

[0057] In one implementation, the participants crypto- 
graphicly sign proposals. Cryptographic signatures offer 
assurances of non-repudiation as well as protection against 
fraud. 

[0058] Vendors and intermediaries may also offer a variety 
of value added services such as warranties, currency con- 
version, financing, training, installation, and maintenance. In 
one implementation, the proposals indicate whether the 
goods are sold with warranties. Intermediaries can extend or 
refuse to honor the warranties in the proposals. For example, 
the IT 125 might be an intermediary specializing in offering 
extended warranties — for a price. Thus, the proposals that 
reach the IP 141 via the IT 125 will indicate a longer 
warranty term and, presumably, a higher price. 

[0059] Similarly, proposals indicate a currency. The ven- 
dors will typically operate only in a single currency, for 
example United States Dollars. Similarly, purchasers typi- 
cally operate only in a single currency, for example British 
Pounds. The trader programs 120 and the manager programs 
130 typically only transmit proposals in a single currency. 
However, the trader programs 120 and the manager pro- 
grams 130 can have a currency conversion table that enables 
them to receive proposals in a currency other than their own 
and transmit a modified proposal in their currency. If the CR 
115 is located in the United States and does business in 
dollars and the IP 141 is located Great Britain and does 
business in pounds, and the IP 141 wants to buy something 
from the CR 115, a proposal will only reach the IP 141 if at 
least one trader program or manager program is willing to 
convert the proposal from dollars to pounds. 

[0060] B. Completing a Transaction 

[0061] FIG. 2A describes one embodiment of a method 
for completing a transaction. 

[0062] At step 200, a purchaser program sends a signal 
requesting a proposal for an item. The purchaser program 
sends the signal when the purchaser wants to buy something. 
The signal could be sent using the WWW over the physical 
layer 100. In one embodiment, the signal is sent by elec- 
tronic mail messages over the physical layer 100. The 
request specifies the item the purchaser would like to buy 
from the vendor operating the cash register program. 

[0063] At step 205, the cash register program receives the 
request and creates a proposal. In one implementation, 
before the cash register program sends the proposal to its 
business relations, the cash register program requests a 
unique identifier from the purchaser program to use in 
identifying the transaction. The unique identifier allows all 
the participants to the transaction to identify the proposal. In 
one implementation, anonymous transactions can also be 
conducted by providing an identifier that does not provide 
identifying information about the purchaser. For example, 
the unique identifier might include the purchaser's name and 
e-mail address, or other identifying information. In an 
anonymous transaction, the unique identifier would not 
include that information. The unique identifier would 
instead contain a number selected by the purchaser program 
or the manager program for the purchaser. 

[0064] At step 210, a search of the business relation 
structures is then conducted to generate a set of proposals for 



the purchaser. In one implementation, this is done by con- 
ducting a breadth first search of business relation structures 
using communications layer 170. This search is described in 
detail below. 

[0065] Next, at step 220, the proposal set is then trans- 
mitted to the purchaser program. Because each intermediary 
in the path between the purchaser and the vendor modifies 
the proposal to reflect the costs of extending credit, the 
purchaser program may receive more than one proposal if 
there was more than one path found in step 210. 

[0066] At step 230, the purchaser program waits for a 
selection signal indicating a proposal is accepted. The 
selected proposal is called an order. In one embodiment 
either the manager program or the purchaser program can be 
configured by a purchaser to automatically accept certain 
proposals based on the originating vendor and the cost, both 
of the current proposal and the amount spent so far that 
month. 

[0067] Once the selection signal is received, at step 240, 
the order, is transmitted to the cash register program. In one 
implementation, the selection signal is transmitted to the 
cash register program by way of the intermediaries corre- 
sponding to the order. 

[0068] At step 250, upon receiving the order, the cash 
register program notifies the purchaser that the order was 
received. In one implementation, the cash register program 
immediately transmits the digital goods bought by the 
purchaser and completes the transaction. If a service has 
been purchased, the cash register program will begin carry- 
ing out the service and provide the purchaser information 
about the status of their transaction. For example, if a foreign 
stock trade was purchased, the cash register program would 
carry out the transaction and provide information to the 
purchaser about the completed transaction by updating the 
WWW page the purchaser is viewing. 

[0069] In one implementation, the cash register program 
also issues a receipt to the purchaser. The receipt acts as a 
proof of purchase for the goods. In one implementation, the 
receipt can also be used for a vendor-designated period to 
re -request the purchased item at no additional charge. 

[0070] It is important to mention that the purchaser need 
not accept any of the proposals. If, for example, all of the 
proposals are undesirable, then the purchaser can decide not 
to select any proposal. In that instance the purchaser pro- 
gram can either transmit a cancellation message to the cash 
register program or simply never complete the transaction 
by never transmitting a selected proposal (causing the pro- 
posals to timeout). Having the programs cryptographicly 
sign proposals can reduce fraud. 

[0071] C. Searching the Business Relation Structures 

[0072] FIG. 2B describes one embodiment of a method of 
searching the business relation structures to generate a set of 
proposals. This can be used in step 210 of FIG. 2A. 

[0073] At step 212, a program (e.g. a trader program) 
receives a proposal. The program could be a trader program 
or a manager program. The proposal specifies the purchas- 
er's identity. The proposal can be processed at this stage to 
ensure that certain preliminary criteria are met. For example, 
proposals that exceed a certain transaction amount can be 
refused. Proposals that have cryptographic signatures that 
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can not be verified can be refused. Also, an intermediary can 
refuse to handle a transaction a second time to avoid the 
creation of loops. If a proposal reaches an intermediary for 
the second time, it is refused and an appropriate error 
message is returned to the sender. Loops are undesirable 
because a loop would increase the price for purchasing the 
good without assisting the process of extending credit to the 
purchaser. 

[0074] Next, al step 214 a routing table is consulted to 
decide if there is a route known to the purchaser. If the 
routing table has an entry for the purchaser, control contin- 
ues at step 2 16 A. If no route exists, control continues at step 
224. 

[0075] At step 216A, the proposal is modified by the 
program to reflect the cost of extending credit and any 
additional value added services the intermediary is provid- 
ing. For example, an intermediary could offer an extended 
warranty and charge for it. The credit risks involved as well 
as the agreements between the parties will also affect the 
markup. These credit risks and agreements are represented 
by the business relation structures. 

[0076] Next, at step 218A, the credit of the party that is 
about to receive the proposal is examined. If the party is 
credit worthy, control proceeds to step 222A. Otherwise, 
control proceeds at step 224. This check is important 
because, business relation structures typically specify a 
maximum amount of credit that can be extended to a party. 
Therefore, it is useful to check that sending the modified 
proposal to the destination will not exceed the credit allowed 
for the destination party. 

[0077] At step 222 A, the proposal is transmitted to the 
destination. It is possible for the destination to be the 
purchaser program. Once the proposal has been successfully 
transmitted, the program stops. If an error occurs during 
transmission, an appropriate error message is returned. 

[0078] At step 224, a list of recipients for the proposal is 
determined. This occurs if there was no route at step 214, or 
if the credit of the proposed route was bad at step 21 8 A. 
Typically, this will be the list of all of the intermediaries and 
purchaser account managers that have business relations 
with the current intermediary. 

[0079] Next, at step 226 the list of recipients is examined. 
If there are no recipients, control proceeds to step 232. If 
there are recipients, control proceeds to step 228. 

[0080] At step 232, as there are no recipients, an error is 
reported back to the intermediary that sent the proposal. The 
sending intermediary will update its routing tables to indi- 
cate that the purchaser cannot be reached through this 
intermediary. 

[0081] At step 228, if each recipient has been sent a 
proposal, the process ends. For each of the recipients, 
control proceeds to block 216B. The process of steps 216B- 
222B can be done in parallel or in sequence for each 
recipient. 

[0082] At step 216B, the proposal is modified for the 
recipient. This process is the same as step 216A and control 
continues at step 218B. 

[0083] At step 218B, the credit of the recipient is checked. 
This process is the same as step 21 8 A, however, if the 



recipient has good credit, control continues with step 222B 
and if the recipient has bad credit, control continues with 
step 218. 

[0084] At step 222B, the modified proposal is transmitted 
to the recipient. This process is the same as step 222A. 
Control then returns to step 228. 

[0085] The error messages that come back from the recipi- 
ents will be used to update the routing table for future 
proposals for the purchaser. Also, when the purchaser 
accepts a proposal, the intermediary will mark the recipient 
intermediary that transmitted the accepted proposal as the 
route to use for future proposals. To ensure that the routing 
tables remain current, they can be purged periodically. 

[0086] Additionally, intermediaries can send messages 
indicating that their status has changed to cause other 
intermediaries to update their routing tables. For example, if 
the intermediary Bank A is brought online in the network, it 
will send a message to its business relations to update their 
routing tables. 

[0087] The routing tables can be purged manually. Routes 
can be manually entered in the routing table. Routes can be 
fixed in place, e.g. so that a particular recipient program is 
the only route used for a purchaser, or multiple purchasers. 

[0088] Also, weightings can be assigned to routes in the 
routing table based on the overall number of successful 
transactions a business relation has completed. For example, 
if an intermediary Bank B has completed a large percentage 
of the transactions for the program, routes relying on that 
intermediary can be favored. For example, if a purchaser P 
has no routing table entry and Bank B has done a high 
complete transaction history, Bank B can be used as a known 
route at step 214. Only if Bank B cannot route the proposal 
to purchaser P will control proceed to step 224. 

[0089] The past credit history of intermediaries can also be 
considered in updating and adding entries to the routing 
table. For example, if an intermediary Bank C is not hon- 
oring its obligations to pay amounts due and there is a bad 
payment history, Bank C will not be used as a recipient at 
step 218A-B. 

[0090] The routing process of FIG. 2B can be bypassed if 
a proposal pre-designates a list of intermediaries to use. In 
that case, the program receiving the proposal ensures that it 
is on the list intermediaries provided by the proposal. If it is, 
the proposal is modified and forward to the next intermedi- 
ary on the list. This is the same as steps 216A-222A; 
however, if the credit of the listed recipient is not satisfac- 
tory, an error will be reported. 

[0091] D, Accepting Proposals 

[0092] FIG. 2C describes one embodiment of a method of 
transmitting the selected proposal to the vendor. This can be 
used in step 240 of FIG. 2A. 

[0093] At step 242, the purchaser program indicates the 
selected proposal by signing it cryptographicly. This reduces 
fraud because it makes it difficult for purchasers to claim that 
they did not request products. In one implementation, the 
use of cryptographic signatures is optional. In one embodi- 
ment, commercially available browser software such as 
Netscape Navigator™ is used to display the set of proposals 
to the purchaser. The proposals can be presented as a 
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hypertext markup language (HTML) document inside the 
browser In one embodiment, each proposal has a corre- 
sponding link associated with it. Alternatively, the proposals 
can be presented and using a Java™ program, a browser 
plugin program, an application program, an electronic mail 
program, or some other program. 

[0094] When the link in the HTML document receives a 
signal, the browser software then, at step 244, transmits the 
acceptance of the proposal to the previous business relation. 
This has the effect of transmitting the selected proposal back 
to the vendor via each of the intermediaries that are facili- 
tating the proposal. For example, the selected proposal may 
have gone from the vendor to Bank X and from Bank X to 
Bank Y and from Bank Y to the purchaser via Bank Y's 
account manager. The signal indicating the selected proposal 
will travel that path in reverse. The signal will be transmitted 
to Bank Y's account manager, then to Bank Y, then to Bank 
X, and finally to the vendor. 

[0095] As the signal indicating the selected proposal is 
transmitted back to the vendor, each program records the 
transaction at step 246. Recording the transaction involves a 
number of subsidiary steps. The receiving program extends 
credit to the intermediary that sent the signal indicating the 
selected proposal. The receiving program updates the busi- 
ness relation structures to reflect the current amount of credit 
extended to business relations. The receiving program 
updates past performance history and past credit history 
appropriately. In one embodiment, the cryptographic signa- 
ture of the sender is verified before recording the transaction. 

[0096] At step 248, if the cash register program can be 
reached, the proposal is transmitted to the vendor. Other- 
wise, at step 248, the process continues at step 244 with the 
transmission of the proposal to the previous business rela- 
tion. 

[0097] At step 249, the cash register program receives the 
proposal and records the transaction. In one embodiment, 
the cryptographic signature of the sending program is veri- 
fied before recording the transaction. In another embodi- 
ment, the cryptographic signature of the purchaser program 
is verified before recording the transaction. Upon recording 
the transaction, the vendor is now obligated to provide the 
products purchased to the purchaser according to the terms 
of the accepted proposal. 

[0098] In one embodiment, the cash register program 
issues a receipt to the purchaser program upon recording the 
transaction. This receipt acts as proof of purchase for the 
goods. The receipt can either be sent directly to the pur- 
chaser over the physical network layer coupling the vendor 
and the purchaser, or the receipt can be sent via the com- 
munications layer. In one embodiment, the receipt can 
specify a period of time in which the purchaser program can 
use the receipt to re-request the goods at no additional 
charge. This is mostly applicable to digitally purchased 
goods. The receipt serves an additional role as insurance 
against a transmission problem in the physical network 
layer. For example, a software product bought electronically 
might permit a two-day re-request period to protect against 
download and transmission failures. In contrast, a stock 
quote would likely come with a much shorter re-request time 
period because the value of product is time sensitive. In one 
embodiment, the cash register program updates the WWW 
page being viewed by the purchaser program to indicate that 



that sale is complete. The updated WWW page might 
contain the information that the purchaser bought or a link 
to the information. In the case of tangible goods, the updated 
page might reflect shipping information. 

[0099] E. Extranet Setup 

[0100] FIG. 3 depicts networked computer systems orga- 
nized to create a transaction network on an extranet using 
one embodiment of the invention. An extranet is an exten- 
sion of a company's internal network, or intranet, that allows 
selected customers, suppliers, and others to access the 
corporate network and vice versa. 

[0101] This paragraph lists the elements of FIG. 3. FIG. 
3 comprises an extranet 300, an IV 301, an IT 311, an IT 312, 
an AM 321, an AM 322, an IP 331, an IP 332, an IP 333, an 
IP 334, a BL351, a BL352, a BL353, a BL354, a BL355, 
a BL 356, a BL 357, and a BL 358. 

[0102] This paragraph describes the interconnections 
between the elements of FIG. 3. The extranet 300 comprises 
the IV 301, the IT 311, the IT 312, the AM 321, the AM 322, 
the BL 351, the BL 352, the BL 353, and the BL 354. The 
IV 301 is coupled to the IT 312 by the BL 351. The IT 312 
is coupled to the IT 311 by the BL 352. The IT 312 is 
coupled to the AM 322 by the BL354. The IT311 is coupled 
to the AM 321 by the BL 353. The AM 321 is coupled to the 
IP 331 by the BL 355. The AM 321 is coupled to the IP 332 
by the BL 356. The AM 322 is coupled to the IP 333 by the 
BL 357. The AM 322 is coupled to the IP 334 by the BL 358. 

[0103] FIG. 3 shows only the communications layer 
where programs are coupled by business links and does not 
show the physical network connections between the com- 
puters running the programs. The cash register programs, the 
trader programs and the account manager programs, that are 
part of the extranet 300, may be running on a single 
computer or multiple computers coupled via a network. The 
extranet 300 is configured to permit a vendor to handle a 
reduced community of companies doing business together. 
The account managers serve as distributors for the vendor. 
This arrangement is desirable for circumstances where a 
vendor prefers to handle its customers directly or the nature 
of the goods for sale by the vendor favors the use of a more 
private network. For example, a vendor might employ the 
extranet 300 for customer support or for providing confi- 
dential information. The extranet 300 can be coupled with 
intermediaries by business links to permit transactions with 
purchasers unknown to the vendor, or outside the extranet 
300, if the vendor so chooses. 

[0104] In the example of FIG. 3, IT 311 has a current table 
with currency conversion rates for United States Dollars and 
British Pounds Sterling. This increases the flexibility of the 
vendor to handle purchasers in different currencies while 
maintaining control of the transaction from the perspective 
of the user. The currency conversion process could also be 
located in the AM 321. Because all of the intermediaries in 
the extranet 300 are more closely controlled by the vendor, 
purchasers will typically only receive a single proposal; 
however, vendors could select multiple distributors to pro- 
vide purchasers choices of warranty terms and financing. 

[0105] F. Corporate Network Setup 

[0106] FIG. 4 depicts networked computer systems orga- 
nized for corporate control of transactions using one 
embodiment of the invention. 
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[0107] This paragraph describes the elements of FIG. 4. 
FIG. 4 comprises a CR 401, a CR 402, a CR 403, a CR 404, 
an IT 411, an IT 412, an IT 413, an IT 414, an AM 420, an 
IP 431, an IP 432, an IP 433, an IP 434, and the BLs 461-472. 

[0108] This paragraph describes the interconnections 
between the elements of FIG. 4. The CR 401 is coupled to 
the IT 411 by BL 461. The CR 402 is coupled to the IT 412 
by BL 462. The CR 403 is coupled to the IT 413 by the BL 
463. The CR 404 is coupled to the IT 414 by the BL 464. The 
ITs 411-414 are coupled to the AM 420 by the BLs 465-468. 
The IPs 431-434 are coupled to the AM 420 by the BLs 
469-472. 

[0109] FIG. 4 depicts the communications layer where 
programs arc coupled by business links and does not show 
the physical network connections between the computers 
running the programs. The trader programs, account man- 
ager programs and purchaser programs in FIG. 4 may be 
running on a single computer or may be running on multiple 
computers coupled by a network. This setup is designed to 
allow a corporation to control electronic commerce between 
its employees and a set of vendors. 

[0110] The vendors and the company have entered into 
agreements with set discounts, payment terms and the like. 
The company then permits its employees to access the 
preferred vendors through the AM 420. The AM 420 can 
impose business rules such as requiring secondary authori- 
zation, budget constraints, auditing requirements, etc. Thus, 
purchasing decisions are easy to control before commitment 
is made to the vendor. Auditing and decision making based 
on internal company rules is also facilitated. 

[0111] G. Component Interactions 

[0112] The following describes component interactions 
and their purpose, according to some embodiments of the 
invention. 

[0113] 1. Cash Register Operation Modes 

[0114] In order to present its items or services for sale, the 
vendor uses an application program such as a web server, an 
electronic storefront program, or some other program. This 
application program handles the basic communications with 
the purchaser until a proposal is requested. At that point, the 
application program sends a message to the cash register 
program that the vendor is running and requests that a 
proposal be generated. The request includes certain param- 
eters for the proposal including a description of items, 
prices, and a manner for connecting to the purchaser. 

[0115] The cash register program may also act as a proxy 
server, such as a hypertext transfer protocol (HTTP) proxy 
server. The cash register program can be programmed to 
automatically intermediate HTTP transmissions from the 
vendor to the purchaser that are tagged in a predefined 
manner. For example, the cash register could look for a 
<META> tag indicating a price. In that instance, the cash 
register program will not permit delivery of the web page to 
the purchaser until the designated price has been paid. 
Alternatively, an extensible markup language (XML) tag 
could be used to signal the cash register program to charge 
for the delivery of content. Alternatively, a different internet 
protocol (IP) could be used to convey the packets to the cash 
register program to charge for the delivery of content. 



[0116] This embodiment offers the unique advantage that 
the existing web server software and other software that 
supports a commerce site does not need to be altered by the 
vendor. A vendor can set up a commerce site using the cash 
register program in proxy mode easily. In this mode, the cash 
register program intercepts packets from the web server, or 
other server, destined for clients. This is done by configuring 
the cash register program as the gateway for packets from 
the web server to the client. This allows the cash register 
program to analyze the intercepted packets to determine if 
there is a price associated with receiving the packets. If the 
cash register program determines that data destined for the 
client has a price, e.g. because there is a <META> tag in the 
HTML indicating a price, the cash register program will 
delay transmission of the data while a proposal is generated 
and routed to the client, purchaser. Only when the client, 
purchaser, has accepted a proposal will the cash register 
program complete the transmission of the data to the client. 
Thus, once the cash register program is the gateway or proxy 
for the web server, commerce functionality is enabled sim- 
ply by providing a flag with the price on any web pages that 
should have a cost. The web page itself might be the good 
purchased, alternatively, the web page might provide a link 
to the good or confirmation that the good is being shipped. 

[0117] In another embodiment, the cash register program 
interacts with a mail server. This enables the cash register 
program to listen for electronic mail and send electronic 
mail and complete the proposal and purchase approval 
process through electronic mail. The cash register program 
can listen for electronic mail from a vendor's application 
program to initiate the proposal process. The cash register 
program then sends an electronic mail to the purchaser 
through the network of business relations. Once an accep- 
tance of a proposal reaches the cash register program by 
electronic mail, an electronic mail is sent to the vendor's 
application program by the cash register program indicating 
that payment has been made and the goods should be 
delivered. 

[0118] In one embodiment, the application program com- 
municates with the cash register program through an inter- 
face designated by the cash register program such as a 
remote procedure call interface, a shared library interface, an 
object linking and embedding interface, or some other 
interface. 

[0119] 2. Manager Program Operation 

[0120] The manager programs are responsible for receiv- 
ing the proposals from the trader programs and conveying 
them to the purchaser. The manager programs communicate 
with a purchaser. The communication can be by electronic 
mail, by direct communication with the purchaser program, 
or through some other communications means. For example, 
the manager program could designate a web page for a 
specific purchaser. The purchaser can then review the web 
page periodically and make her/his selections. In another 
embodiment, the purchaser program could be activated by a 
message from the manager program and display the propos- 
als to the user immediately. 

[0121] H. Sample Data Structures and Implementation 

[0122] The following describes data structures and their 
use, according to some embodiments of the invention. 
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[0123] 1. Data Structures 

[0124] One implementation uses several different data 
structures to complete transactions. The basic data structures 
are a purchaser identifier, a role identifier, a currency iden- 
tifier, a time stamp, an Internet Protocol address identifier, 
transaction identifiers, and a good identifier. These basic 
data structures are in turn used to create more complex data 
structures. Some of these complex data structures are for 
storing prices, transactions, tokens, tickets, and signatures. 

[0125] A price data structure comprises an amount and a 
currency identifier. The amount is expressed as an integer in 
thousandths of the currency unit. For example, if the cur- 
rency identifier specifies that United States Dollars are used, 
then one dollar would be represented by the amount "1000." 
The amount could also be specified as an amount per unit. 
For example, time at a computer controlled telescope might 
be purchased in minutes, therefore a proposal could specify 
an amount per unit. 

[0126] A transaction data structure comprises a role iden- 
tifier, a time stamp, and a transaction identifier. The role 
identifier designates the vendor or intermediary who is 
creating the transaction data structure. The time stamp 
specifies the time at which the transaction data structure was 
created. The transaction identifier can uniquely identify a 
specific transaction for all participants. 

[0127] The token data structure comprises a role identifier, 
a time stamp, and a transaction identifier. The role identifier 
will designate the account manager who is creating the token 
data structure. 

[0128] Ticket data structures serve as a receipt for goods 
or services that have been sold. One important purpose 
served by the ticket data structure is to permit users to 
re-request digital goods that did not properly download 
across the network. Ticket data structures comprise a role 
identifier, a good identifier, a purchaser identifier, a time 
stamp, a duration, and a signature. The role identifier des- 
ignates the vendor who is creating the ticket data structure. 
The duration specifies the number of seconds from the time 
indicated by the time stamp for which the ticket can be used 
to re-request the good identified by the good identifier. The 
signature is a signature data structure. 

[0129] The signature data structure comprises a type iden- 
tifier and a signature. The type identifier describes what 
security protocol was used to create the signature. The 
signature can be a digital signature created by public key 
cryptography based on X.509 certificates. When business 
relationships are formed initially, parties to the business 
relationships exchange or create certificates to enable digital 
signatures. In order to speed the transaction process, parties 
in a business relationship may agree to sign only certain 
transactions, e.g. those exceeding a certain dollar amount. 
Additionally, the parties in a business relationship can 
periodically trade signed messages containing details of 
many previously unsigned transactions. 

[0130] 2. Communications Protocol 

[0131] The following describes the communications pro- 
tocol used in some embodiments. The communications 
protocol describes the messages that are communicated 
between the parties to initiate, monitor, and complete a 



transaction. The messages can be transmitted over the net- 
work using the Transmission Control Protocol (TCP) or 
other protocols. 

[0132] A vendor asks purchasers to identify themselves by 
transmitting information about the good to the purchaser. 
This is called a purchaser information request message and 
it comprises a good identifier, a description of the good, and 
information about whether or not anonymous transactions 
are permitted. In one implementation vendors can indicate 
that anonymous transactions are permitted, forbidden, or 
that they prefer not to do anonymous transactions. 

[0133] Upon receiving purchaser information requests, 
purchasers transmit to the cash register, their certificate. The 
certificate is an identifier that was provided to the purchaser 
when they formed their business relationship with their 
account manager. The certificate uniquely identifies the 
purchaser. The account manager is not involved in this stage 
because the purchaser program stores its certificate locally. 
If a purchaser prefers anonymity, they can request an anony- 
mous certificate from their account manager that contains a 
nickname rather than their true identity. This prevents parties 
other than the account manager from matching the a pur- 
chaser request with a purchaser. Similarly, the vendor can 
describe its goods generically to prevent account managers 
from monitoring purchases. 

[0134] The communications protocol defines messages for 
transmitting ticket data structures and using ticket data 
structures to re-request delivery of goods. The communica- 
tions protocol defines messages for providing the user a 
descriptive message on the progress of the transaction. In the 
case of errors, an error message is used that describes the 
error and identifies the intermediary or account manager that 
is preventing the transaction from being completed. 

[0135] Still further messages are used by the communica- 
tions protocol between participants. Proposal messages are 
sent between participants. Proposal messages represent a 
firm offer from a vendor to sell the designated good at the 
designated price. Proposal messages are modified by par- 
ticipants to reflect the cost of extending credit. Proposal 
messages include information such as the period for which 
the proposal is valid, the warranty terms, and a crypto- 
graphic signature by the sender. 

[0136] Approval messages are sent by the purchaser 
through the sequence of business links identified by the 
proposal back to the vendor to indicate the acceptance of a 
proposal. Approval messages include the transaction iden- 
tifier, the price, and a cryptographic signature. Similarly, 
user cancellation messages can be used by the purchaser to 
indicate that they do not wish to purchase an item. 

[0137] Invoice and refund messages are sent by the vendor 
to the purchaser through the sequence of business links 
identified by the accepted proposal. Invoice messages are 
sent after the purchaser has sent an approval message to 
cause the intermediaries and the account manager to record 
the transaction. Refund messages are used to roll back 
transactions that have been invoiced. Each proposal can 
specify a maximum amount period for a refund and once that 
period expires, the transaction can not be rolled back. 

[0138] Other components of the communications protocol 
are used to maintain information for routing proposals in the 
communications layer as well as for error recovery and error 
reporting. 
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[0139] 3. Finding Sequences of Business Links 

[0140] Because transactions and proposals occur along 
sequences of business links, or credit routes, that couple the 
cash register program and the purchaser program, it is 
important for intermediaries to maintain routing information 
that will speed the delivery of proposals to purchasers. 

[0141] As messages are transmitted using the communi- 
cations protocol a variety of error messages will be gener- 
ated by participants should transmissions fail or time out. 
The error messages can be used to maintain routing infor- 
mation. Further, participants can send a message requesting 
new routing information. By using the information gathered 
in the process of using the communications protocol to 
maintain the routing table, the number of recipients for each 
proposal is reduced. 

[0142] In one implementation, the routing table used by 
intermediaries is organized based on account managers. 
Entries in the routing table comprise a destination, an 
identifier for the next recipient and a mark. The destination 
is a account manager identifier. The next recipient is either 
another intermediary or the account manager. The mark is 
one of three values: best route, possible route, and no route. 
The mark is used to decide which entry for a account 
manager will be used to convey a proposal. 

[0143] As a request is made to convey a proposal to a 
account manager, the routing table is consulted. If there no 
entry for that account manager, then the intermediary must 
find a new path. This is accomplished by sending the 
proposal to all of the intermediary's business relations, 
except for the intermediary that sent the proposal, and 
waiting. The information conveyed back to the intermediary 
by the communications protocol allows the intermediary to 
mark the route in the routing table. If a business relation of 
the intermediary sends a message that no route is possible 
then an entry is made in the routing table with the account 
manager identifier, the identifier for that business relation, 
and the mark no route. If a business relation of the inter- 
mediary is used to convey a proposal successfully, an entry 
is made in the routing table with the account manager 
identifier, the identifier for that business relation, and the 
mark best route. The other business relations all receive 
entries marked as possible routes. 

[0144] If upon receiving a request to convey a proposal to 
a account manager with entries in the routing table, the 
routing table information is used. The proposal is first sent 
along the entry marked best route and only sent along the 
other routes if an error occurs. Routing table entries have 
their marks changed in response to messages. For example, 
if the entry with the mark of best route fails to convey the 
proposal, the entry will be changed so the mark is possible 
route. 

[0145] In order to maintain the quality of the routing table, 
the information is periodically refreshed. This can occur 
using communications protocol messages that request that 
business partners reset the sender's routing information. For 
example, if Bank X has not received many proposals from 
Bank Y, Bank X could send a route-reset message to Bank 
Y. Upon receiving the route- reset message, Bank Y would 
then update its routing table entries for Bank X. Addition- 
ally, each intermediary might also reset the marks for routing 
table entries periodically to ensure the discovery of new 
routes. 



[0146] 4. Transaction Overview 

[0147] This section describes the usage of the data struc- 
tures, the communications protocol, and the routing tables in 
a sample transaction. 

[0148] The purchaser uses his/her computer to access the 
Internet. The purchaser can use commercially available 
browser software such as Netscape Navigator™ to view 
WWW pages and review information. Other programs can 
also be used to access the Internet such as Java™ applica- 
tions, plug-in programs, electronic mail programs, and other 
software programs. The items that are for sale can be 
presented in HTML or some other fashion. When the pur- 
chaser signals that he/she is interested in an item that is for 
sale the following occurs. 

[0149] The cash register program uses the communica- 
tions protocol to request information about the purchaser 
from the purchaser program. The information is then con- 
veyed back to the cash register program with a purchaser 
information provided message. 

[0150] The cash register program then uses the informa- 
tion about the purchaser to create the proposal. The proposal 
is then sent to the vendor's intermediary. The intermediary's 
trader program receives the proposal and adds a markup. 
The trader program then uses the routing tables to find a 
route to convey the proposal to the purchaser's account 
manager. 

[0151] The manager program receives proposals and for- 
wards them to the purchaser program. The purchaser pro- 
gram on the purchaser's computer displays the proposals. 
The proposals could be displayed directly in the browser or 
might be shown using a Java™ program, browser plug-in, 
electronic mail programs, or some other program. The 
purchaser can then accept one of the proposals or reject them 
by selecting a proposal from the list. The purchaser program 
then uses that selection to send an appropriate message. In 
the case where the purchaser has approved a proposal, an 
approval message will be sent. 

[0152] The purchaser program then transmits the appro- 
priate message to the manager program in response to the 
purchaser's signal. The manager program then conveys the 
approved proposal to the cash register program using the 
reverse sequence of business links that conveyed the pro- 
posal to the purchaser. 

[0153] Upon receiving the approval message, the cash 
register program sends a receipt, ticket data structure, to the 
purchaser program. The vendor also delivers the order to the 
purchaser. Invoice messages are sent by the cash register 
program to close out the transaction. 

[0154] I. Alternative Embodiments 

[0155] Some embodiments of the invention are included in 
computer usable media such as CD-ROMs, or other com- 
puter usable media. The computer usable media can com- 
prise the software for cash register programs, trader pro- 
grams, manager programs, and purchaser programs. 

[0156] Some embodiments of the invention are included in 
one or more of the programs on the intermediaries, account 
managers, or purchaser computers. 

[0157] Some embodiments of the invention are included in 
an electromagnetic wave form. The electromagnetic wave 
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form comprises information such as proposals, approval 
messages, and other messages that comprise the communi- 
cations between the participants in a transaction, or the 
programs. 

[0158] J. Conclusion 

[0159] Thus, a method and apparatus for electronic com- 
merce has been described. The method permits vendors and 
purchasers to complete transactions over a network. The 
method enables a large volume of low priced transactions by 
facilitating the extension of credit to purchasers without 
requiring the vendor to act as the creditor. The system offers 
unique benefits for the global nature of Internet commerce 
by permitting the conversion of currencies and payment 
methods. 

[0160] The system enables corporations to decentralize 
their purchasing process while keeping control of their 
expenses. Further, the system enables the purchases to be 
linked with internal account numbers and budget items at the 
time of purchase. This enables a community of businesses to 
handle their business flow efficiently when the goods and 
invoices are flowing along different paths. Further, this 
system enables the rapid deployment of commercial sites 
through the proxy setup of the cash registers. 

What is claimed is: 

1. A method of communicating an acceptance of a pro- 
posal via a plurality of computers coupled in communication 
in a network, said proposal identifying a good to be pur- 
chased and a price, said price describing the cost for 
purchasing said good using said proposal, said plurality of 
computers including a vendor computer and a purchaser 
computer, said network supporting a plurality of business 
relation structures, each business relation structure of said 
plurality of business relation structures representing an 
agreement to extend credit between at least two businesses, 
said method comprising: 

generating a first proposal from said vendor computer, 
said first proposal identifying said good and a first 
price, said first price corresponding to the cost of 
purchasing said good using said first proposal; 

generating a set of proposals from said first proposal and 
said plurality of business relation structures, wherein 
said generating includes, 

searching said plurality of business relation structures 
to determine a plurality of paths between said vendor 
computer and said purchaser computer, each path in 
said plurality of paths corresponding to a sequence of 
business relation structures between said vendor 
computer and said purchaser computer, 

creating said set of proposals, each proposal of said set 
of proposals having a corresponding path in said 
plurality of paths, and 

including in each proposal of said set of proposals any 
changes in said first price as a result of the business 
relation structures used to extend credit; 

transmitting said set of proposals to said purchaser com- 
puter; 

receiving a selection of said proposal from said set of 
proposals; and 



transmitting said selection to said vendor computer indi- 
cating said proposal is accepted. 

2. The method of claim i wherein said generating said 
first proposal from said vendor computer includes: 

signing said first proposal using a cryptographic key 
identifying said vendor computer. 

3. The method of claim 1 wherein said searching said 
plurality of business relation structures to determine said 
plurality of paths between said vendor computer and said 
purchaser computer includes: 

a breadth first search of said plurality of business relation 
structures. 

4. The method of claim 1 wherein said searching said 
plurality of business relation structures to determine said 
plurality of paths between said vendor computer and said 
purchaser computer includes: 

maintaining a plurality of past credit histories, each past 
credit history of said plurality of past credit histories 
having a corresponding business relation structure in 
said plurality of business relation structures; 

eliminating from said plurality of paths each path whose 
corresponding sequence of business relation structures 
between said vendor computer and said purchaser 
computer includes a business relation structure whose 
corresponding past credit history is unfavorable, 

5. The method of claim 1 wherein said generating said set 
of proposals from said first proposal and said plurality of 
business relation structures includes: 

maintaining a plurality of past results of said searching 
said plurality of business relation structures; 

eliminating from said plurality of past results each past 
result which is older than a predetermined period; 

generating said set of proposals using said plurality of 
past results if at least one past result of said plurality of 
past results has not been eliminated. 

6. The method of claim 1 wherein each business relation 
structure specifies a total credit value, said total credit value 
indicating a total amount of credit that can be extended 
under said agreement represented by said business relation 
structure, said searching said plurality of business relation 
structures to determine a plurality of paths between said 
vendor computer and said purchaser computer includes: 

generating a plurality of current credit values, each cur- 
rent credit value of said plurality of current credit 
values having a corresponding business relation struc- 
ture, each current credit value indicating an amount of 
credit currently extended between said at least two 
businesses in said corresponding business relation 
structure; 

eliminating from said plurality of paths each path whose 
corresponding sequence of business relation structures 
between said vendor computer and said purchaser 
computer includes a business relation structure whose 
corresponding current credit value exceeds said total 
credit value corresponding to said business relation 
structure; and 

eliminating from said plurality of paths each path whose 
corresponding sequence of business relation structures 
between said vendor computer and said purchaser 
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compwcr includes a business relation structure whose 
corresponding current credit value plus said price 
specified by said proposal corresponding to said path 
exceeds said total credit value specified by said busi- 
ness relation structure. 

7. The method of claim 1 wherein said price of said first 
proposal is specified in a first currency and said proposal 
specifies that said purchaser computer requires that said 
price be specified in a second currency, said including in 
each proposal of said set of proposals any changes in said 
first price as a result of the business relation structures 
needed to extend credit includes: 

specifying said price in said second currency; and 

adding to said price charges for converting from said first 
currency to said second currency. 

8. The method of claim 1 wherein said including in each 
proposal of said set of proposals any changes in said first 
price as a result of the business relation structures needed to 
extend credit includes: 

at least one or more of adding a warranty to at least one 
proposal in said set of proposals, eliminating a war- 
ranty from at least one proposal in said set of proposals, 
and changing said price of at least one proposal of said 
set of proposals based on whether or not said at least 
one proposal has a warranty. 

9. The method of claim 1 wherein said including in each 
proposal of said set of proposals any changes in said first 
price as a result of the business relation structures needed to 
extend credit includes 

changing said price to specify said price as financing 
terms for the purchase of said good in installment 
payments. 

10. The method of claim 1 wherein said transmitting said 
set of proposals to said purchaser computer includes: 

transmitting each proposal of said set of proposals to each 
computer of said plurality of computers in the corre- 
sponding path from said vendor computer to the said 
purchaser computer. 

11. The method of claim 1 wherein said transmitting said 
set of proposals to said purchaser computer includes: 

using a cryptographic key to sign each proposal of said set 
of proposals. 

12. The method of claim 1 wherein said receiving said 
selection of said proposal from said set of proposals 
includes: 

signing said proposal using a cryptographic key identify- 
ing said purchaser computer. 

13. The method of claim 1 wherein said transmitting said 
selection to said vendor computer indicating said proposal is 
accepted includes: 

transmitting said selection to each computer of said 
plurality of computers in said path from said purchaser 
computer to said vendor computer corresponding to 
said proposal. 

14. A method of facilitating the transmission of a proposal 
with a first computer using a plurality of computers coupled 
in communication by a network, said proposal identifying a 
good to be purchased, a price describing the cost for 
purchasing said good using said proposal, identifying a 
purchaser computer requesting said proposal and identifying 



a vendor computer offering said proposal, said network 
supporting a plurality of business relation structures repre- 
senting an agreement to extend credit between at least two 
businesses, said method comprising: 

determining a first set of business relation structures to 
receive proposals from; 

receiving said proposal on said first computer, said pro- 
posal being sent from a business relation structure in 
said first set of business relation structures; 

determining whether to facilitate said proposal; and 

responsive to said determining: 

modifying said proposal as a result of the business 
relation structures used to extend credit, 

determining a second set of business relation structures 
to receive said proposal, and 

transmitting said proposal to said second set of business 
relation structures from said first computer. 

15. The method of claim 14 wherein said determining said 
second set of business relation structures to receive said 
proposal includes: 

maintaining a plurality of past credit histories, each past 
credit history of said plurality of past credit histories 
having a corresponding business relation structure in 
said plurality of business relation structures; 

eliminating from said second set of business relation 
structures each business relation structure whose cor- 
responding past credit history is unfavorable. 

16. The method of claim 14 wherein said determining said 
second set of business relation structures to receive said 
proposal includes: 

maintaining a plurality of past fraud histories, each past 
fraud history of said plurality of past fraud histories 
having a corresponding business relation structure in 
said plurality of business relation structures; 

eliminating from said second set of business relation 
structures each business relation structure whose cor- 
responding past fraud history is above a predetermined 
limit. 

17. The method of claim 14 wherein said modifying said 
proposal as a result of the business relation structures needed 
to extend credit includes: 

increasing said price to reflect the cost of extending credit. 

18. The method of claim 14 wherein said price is specified 
in a first currency and said proposal specifies that said 
purchaser computer requires that said price be specified in a 
second currency said modifying said proposal as a result of 
the business relation structures needed to extend credit 
includes: 

specifying said price in said second currency; and 

increasing said price to reflect the cost of converting from 
said first currency to said second currency. 

19. The method of claim 14 wherein said modifying said 
proposal as a result of the business relation structures needed 
to extend credit includes: 

changing said price to specify said price as financing 
terms for the purchase of said good in installment 
payments. 
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20. The method of claim 14 wherein each business 
relation structure specifics a corresponding total credit 
value, said total credit value indicating a total amount of 
credit that can be extended between said agreement repre- 
sented by said business relation structure, said determining 
a second set of business relation structures to receive said 
proposal includes: 

generating a plurality of current credit values, each cur- 
rent credit value of said plurality of current credit 
values having a corresponding business relation struc- 
ture, each current credit value indicating the amount of 
credit currently extended between said at least two 
businesses in the corresponding business relation; 

eliminating from said second set of business relation 
structures each business whose corresponding current 
credit value exceeds said total credit value correspond- 
ing to said business relation structure; and 

eliminating from said second set of business relation 
structures each business relation structure whose cor- 
responding current credit value plus the amount of 
credit needed to complete said proposal exceeds said 
total credit value corresponding to said business rela- 
tion structure. 

21. The method of claim 14 wherein said determining said 
second set of business relation structures to receive said 
proposal includes: 

maintaining a plurality of past acceptance histories, each 
past acceptance history of said plurality of past accep- 
tance histories having a corresponding business rela- 
tion structure in said plurality of business relation 
structures; and 

eliminating from said second set of business relation 
structures each business relation structure whose cor- 
responding past acceptance history is lower than a 
predetermined amount, 

22. The method of claim 14 wherein said transmitting said 
proposal to said second set of business relation structures 
includes: 

signing said proposal using a cryptographic key identify- 
ing said first computer. 

23. The method of claim 14 wherein said proposal 
includes a cryptographic signature, said determining 
whether to facilitate said proposal includes: 

verifying said cryptographic signature; and 

refusing to facilitate transactions when said cryptographic 
signature can not be verified. 

24. A system of communicating the acceptance of a 
proposal via a plurality of computers coupled in communi- 
cation in a network, said proposal identifying a good to be 
purchased and a price, said price describing the cost for 
purchasing said good using said proposal, said plurality of 
computers including a vendor computer and a purchaser 
computer, said network supporting a plurality of business 
relation structures, each business relation structure of said 
plurality of business relation structures representing an 
agreement to extend credit between at least two businesses, 
said system comprising: 

a means for generating a first proposal from said vendor 
computer, said first proposal identifying said good and 



a first price, said first price corresponding to the cost of 
purchasing said good using said first proposal; 

a means for generating a set of proposals from said first 
proposal and said plurality of business relation struc- 
tures, wherein said means for generating a set of 
proposals includes, 

a means for searching said plurality of business relation 
structures to determine a plurality of paths between 
said vendor computer and said purchaser computer, 
each path in said plurality of paths corresponding to 
a sequence of business relation structures between 
said vendor computer and said purchaser computer, 

a means for creating said set of proposals, each pro- 
posal of said set of proposals having a corresponding 
path in said plurality of paths, and 

a means for including in each proposal of said set of 
proposals any changes in said first price as a result of 
the business relation structures used to extend credit; 

a means for transmitting said set of proposals to said 
purchaser computer; 

a means for receiving a selection of said proposal from 
said set of proposals; and 

a means for transmitting said selection to said vendor 
computer indicating said proposal is accepted. 

25. A computer program product comprising: 

a computer usable medium having a computer readable 
program code embodied therein, the computer program 
comprising: 

a set of instructions for receiving a first input, the first 
input comprising an attempted transmission of data 
to a requester, the data corresponding to a good and 
a price of the good; 

a set of instructions for generating a first output from 
the first input, the first output corresponding to an 
offer for the purchase of the good at the price; 

a set of instructions for receiving a second input, the 
second input indicating an acceptance of the offer; 
and 

a set of instructions for generating a second output for 
the requestor upon acceptance of the offer, the sec- 
ond output corresponding to the attempted transmis- 
sion of data. 

26. The computer program product of claim 25 wherein 
the data is a hypertext transfer protocol response comprising 
a document and said good includes the content of the 
document. 

27. The computer program product of claim 25 wherein 
the data is a hypertext transfer protocol response comprising 
a document and the flag is at least one or more of a header, 
a hypertext markup language tag, and an extensible markup 
language tag. 

28. The computer program product of claim 25 wherein 
the second output corresponds to a confirmation that the 
good designated by the data has been purchased. 
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29. The computer program product of claim 25 wherein 
the second output is a hypertext transfer protocol response 
comprising a document and the document includes a hyper- 
text Link for accessing a good designated by the data. 

30. A computer data signal embodied in a carrier wave 
comprising: 

a computer program, the computer program comprising: 

a routing table, the routing table containing entries for 
a plurality of purchasers and for each purchaser a 
corresponding intermediary; 

a set of instructions for examining a proposal, the 
proposal for the purchase of a good by a purchaser, 
to determine the purchaser; 

a set of instructions for determining if the purchaser has 
at least one corresponding intermediary in the rout- 
ing table; and 

a set of instructions for transmitting the proposal to the 
at least one corresponding intermediary in the rout- 
ing table. 



31. The computer data signal of claim 30 wherein the 
proposal includes a price, and said set of instructions for 
transmitting the proposal includes: 

a set of instructions for modifying the price of the 
proposal; 

a set of instructions for verifying that the corresponding 
intermediary in the routing table has not exceeded a 
predetermined credit limit; and 

a set of instructions for transmitting the proposal to the 
corresponding intermediary only if the predetermined 
credit limit has not be exceeded. 

32. The computer data signal of claim 30 wherein said set 
of instructions for determining if the purchaser has a corre- 
sponding intermediary in the routing table includes: 

a set of instructions for generating a set of intermediaries 
to receive the proposal, said at least one intermediary 
being said set of intermediaries. 

* * ♦ * * 
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